REMARKS 

Claim amendments 

The original claims contained two claims with the number 15. By this 
amendment the applicants have renumbered the claims consecutively from 1 to 33. The 
claim identifier "currently amended" is used for the renumbering of the claims. 

Claims 11-13 have been amended to insert email content and in the claims to 
provide antecedent basis for "said email content" later in the claim and avoid any § 112 
issues. 

Anticipation Rejection 

Claims 1-33 are rejected as anticipated by Wolfe U.S. 6,507,817. The rejection is 
in error and should be withdrawn as explained below. 

This application relates to rendering of email and claims several related features. 
None of the independent claims are disclosed whatsoever in Wolfe. 

Claim 1 

In claim 1, tags are inserted into the email which separate content from one source 
("first source") from the content of another source ("second source"). The tags are 

detected (e.g., in a voice command platform that features a text to speech engine for 
rendering email as speech) and the content from the first source is rendered in a first 
voice mode (e.g., with a man's voice) and content from the second source is rendered in a 
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second voice mode (e.g., with a woman's voice). The feature of the tags and rendering 
content from different sources in different voice modes helps the email recipient 
understand the breaks in the email between sources and distinguish for example an 
original email from a reply. 

Wolfe does not even come close to disclosing the invention of claim 1. Wolfe is 
directed to a system for using text based forms for things like purchasing, requesting 
information, scheduling appointments, etc. See Backgroimd at col. 2 lines 19-67. The 
Wolfe reference described a facility of form approval by a subscriber or approving party. 
Summary at col. 28-45. An application server may render the text-based form in audible 
format and the subscriber or approving party can then take action such as approve or 
deny the form. The Wolfe reference contemplates that the approving party may have the 
form rendered as speech and may provide a voice response to approve or deny the form. 
See id., see also col. 8 lines 7-43. 

The Examiner cites to Wolfe at col. 6 lines 40-59. The context of the passage 
cited by the Examiner is that it is describing a form approval process (not the rendering of 
email as speech, inserting tags into email, or rendering email in different voice modes). 
Wolfe's form approval system involves an application server, HTTP requests, the 
accessing of XML documents that define application operations to be performed based on 
parameters specified within the HTTP request, and the application state. Wolfe, Col. 6 
lines 19-39. 

Wolfe at col. 6 lines 40-59 states as follows: 

The voice application server 66 is configured for accessing service application 
programming interfaces (APIs) 82 to. external resources based on prescribed 
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procedures that may be called during parsing of an XML tags in a selected XML 
document 68. As described below, the application server 66 issues function calls to 
an API 82 for accessing the external resources for prescribed operations. In particular, 
the application server 66 accesses subscriber profile information from an. IP-based 
database server 84 according to lightweight directory access protocol (LDAP). As 
disclosed in commonly assigned, co-pending application Set. No. 09/588,293, filed 
Jim. 7, 2000, entitled Unified Messaging System Using Web Based Application 
Server For Management of Messages Using Standardized Servers the disclosure of 
which is incorporated in its entirety herein by reference, the application server 66 may 
issue function calls for storing and retrieving messages in a standardized format (e.g., 
e-mail with binary encoded attachments) in an internet message access protocol 
(IMA?) messaging server 86, or for a text-to-speech resource 88. 



Wolfe is simply teaching in this passage that the voice application server 66 may access 
external resources via function calls for prescribed operations, such as storing and 
retrieving messages in a standardized format such as email, and accessing a text-to- 
speech resource. The passage says nothing about inserting tags into email, detecting the 
tags when rendering email, or rendering the email in different voice modes. The 
passage clearly does not anticipate claim 1 . 

In the following paragraph, Wolfe states: "Hence, the voice application server 66 
may access the text-to-speech resource 88 for converting an e-mail text message into an 
audio-based message to be played for the user of the telephony device 1 8. As described in 
further detail below, this audio-based playback of an e-mail message stored in the IMAP 
message store enables a user of the telephony device 1 8 to approve submitted forms using 
the telephone 1 8." Wolfe, col. 6 lines 60-67. This is further explained in the example at 
col. 7 lines 57- col. 8 line 53. While email is used as a vehicle for submitting forms for 
approval and the email may be rendered as speech, the reference does not describe the 
features of claim 1 of inserting tags into the email, detecting the tags, and rendering the 
email in different voice modes as claimed in claim 1 . Nothing in the passages cited by 
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the Examiner in Wolfe say anything about rendering email in different voice modes. 
Claim 1 is therefore not anticipated by Wolfe. 

Claim 5 

Claim 5 is similar to claim 1 and describes a method which requires identifying an 
original email message and a reply message, rendering the original email in one voice 
mode and the reply message in a different voice mode. 

Wolfe does not even come close to disclosing the invention of claim 5. The 
Examiner cites to Wolfe at col. 6 lines 40-59. Wolfe is simply teaching in this passage 
that the voice application server 66 may access external resources via function calls for 
prescribed operations, such as storing and retrieving messages in a standardized format 
such as email, and accessing a text-to-speech resource. The passage says nothing about 
rendering an original email in one voice mode and a reply in a different voice mode. 
Wolfe clearly does not anticipate claim 5. 
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Claim 1 1 

Claim 1 1 is directed to a method of rendering email as speech. In the method, the 
email is processed to identify email content and a signature block in the email message. 
The email content is rendered as speech but the signature block is not rendered, thereby 
improving the user experience. ' 

Wolfe does not even come close to disclosing the invention of claim 1 1 . The 
Examiner cites to Wolfe at col. 6 lines 40-59. Wolfe is simply teaching in this passage 
that the voice application server 66 may access external resources via function calls for 
prescribed operations, such as storing and retrieving messages in a standardized format 
such as email, and accessing a text-to-speech resource. The passage says nothing about 
detecting a signature block, or rendering email content but not rendering the signature 
block as speech. Wolfe clearly does not anticipate claim 1 1 . 

Claim 12 

Claim 12 is similar to claim 11 but identifies a privacy notice in an email and 
renders the email content but not the privacy notice as speech. Wolfe at col. 6 says 
nothing about detecting privacy notices and not rendering them. Wolfe clearly does not 

anticipate claim 12. 

' The Applicants' representative has the following email signature block: 

Thomas A. Fairhall 

fairhall@.mbhb.com 

ph. 360 379 6514 

fax 360 379 2434 

McDonnell Boehnen Hulbert & Berghoff LLP 

1136 Water Street 

Port Townsend WA 98368 

If this was rendered every time as speech to a frequent email recipient, it would be 
annoying. This annoyance is avoided in the invention of claim 5. 
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Claim 13 

Claim 1 3 is similar to claims 1 1 and 12, except that the method processes email to 
detect a confidentiality notice. The email content is rendered as speech by the 
confidentiality notice is not. For example, suppose an email source appends the 
following confidentiality notice and sends many emails a week to the same recipient: 
"This communication (including any attachments) contains information which is 
confidential and may also be privileged. It is intended for the exclusive use of the 
intended recipient(s). If you are not an intended recipient, please do not distribute, copy 
or use the communication or the information. Instead, please notify the sender 
immediately and then destroy any copies of it. Due to the nature of the Internet, the 
sender is unable to ensure the integrity of this message and does not accept any liability 
or responsibility for any errors or omissions (whether as the result of this message having 
been intercepted or otherwise) in the contents of this message." Again, it would be very 
annoying for the recipient to hear this message every time an email from the source is 
rendered as speech. 

Wolfe at col. 6 says nothing about detecting confidentiality notices and not 
rendering them. Wolfe clearly does not anticipate claim 13. 

Claim 14 

Claim 14 is similar to claim 5, but adds that the method refers to a user profile to 
determine whether to render a signature block as speech, and renders or not renders the 
signature block in accordance with the user profile. For example, some users may want 
to hear the signature block to make sure they can contact the person, e.g., via phone or 
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fax. Wolfe not only does not process email to identify both email content and signature 
blocks, it says nothing about referencing a user profile to determine whether to render or 
not render a signature block as speech. The Examiner has not cited to anything in Wolfe 
for this teaching. There is no prima facie case of anticipation established by the 
Examiner. The Examiner cites to Wolfe at col. 6 lines 40-59. Wolfe is simply teaching 
in this passage that the voice application server 66 may access external resources via 
fimction calls for prescribed operations, such as storing and retrieving messages in a 
standardized format such as email, and accessing a text-to-speech resource. The passage 
says nothing about detecting a signature block, or rendering email content but not 
rendering the signature block as speech depending on the contents of a user profile. 
Wolfe clearly does not anticipate claim 14. 

Claim 15 

Claim 15 is similar to claims 5, 1 1 and 14, but describes a feature for prompting a 
user to indicate whether to render a signature block as speech, and then rendering or not 
rendering signature blocks as speech in accordance with the response to the prompt. 
Nothing in Wolfe describes detecting tags separating content from signature blocks, or 
prompting users to indicate whether or not to render a signature block as speech. The 
Examiner has not cited to anj^ing in Wolfe for this teaching. There is no prima facie 
case of anticipation established by the Examiner. It certainly is not disclosed in col. 6 of 
Wolfe. 
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Claim 16 

Claim 1 6 is in Jepson form and describes an improvement to an email server in 
the form of a machine readable storage medium storing instructions for parsing an email 
to detect email content and signature blocks, and inserting a tag in the email message that 
separates email content from the signature block. Nothing of the sort is described in 
Wolfe. The Examiner cites to Wolfe at col. 6 lines 40-59. Wolfe is simply teaching in 
this passage that the voice application server 66 may access external resources via 
function calls for prescribed operations, such as storing and retrieving messages in a 
standardized format such as email, and accessing a text-to-speech resource. The passage 
says nothing about detecting a signature block, or inserting a tag into the email that 
delineates between the email content (e.g., "Hi Bob, I will meet you after the game.") and 
the signature block (e.g., "joesmith@greatco.com. Joe W. Smith, Account Executive, 
Great Company, Inc., 123 Grand Avenue Chicago IL 60606, ph. 312-876-2726"). 

Claim 17 

Claim 17 is in Jepson form and is directed to an improved email server which 
includes instructions for parsing an email to detect content from a first source (e.g., 
original email author) and second source (recipient of the original email), and instructions 
inserting a tag in the email message that separates the email content from the first source 
from the email content of the second source. As explained in the specification an email 
with these tags can be used by the voice command platform to render the content from 
the first source in one voice mode (accent, pitch, gender, etc.) and the content from the 
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second source in a different voice mode. The remarks for claim 1 are incorporated by 
reference here. Wolfe is silent on parsing email as claimed or inserting tags to delineate 
email content from different sources. The Examiner has not made out a prima facie case 
of anticipation of claim 17. 

Claim 18 

Claim 18 is similar to claim 17 but instead of inserting tags to distinguish between 
content from different sources the email server includes instructions to insert tags that 
separate content from confidentiality and/or privacy notices. The remarks for claims 12 
and 13 are incorporated by reference here. Wolfe does not parse email and inserts tags as 
recited in claim 18, and does not describe parsing email to distinguish between email 
content and privacy and/or confidentiality notices. Wolfe clearly does not anticipate 
claim 18. 

Claim 19 

Claim 19 is directed to a method of allowing a recipient of an email message to 
respond via voice, and involves receiving a signal from a recipient indicating that the 
recipient intends to respond to the email message by inserting a voice memo at a 
particular location in the email message. The signal is received while the email is being 
rendered as speech. The Examiner has not cited to anything in Wolfe that discloses this 
feature. At most, the Examiner cites to Wolfe at col. 6 lines 40-59. Wolfe is simply 
teaching in this passage that the voice application server 66 may access external 
resources via function calls for prescribed operations, such as storing and retrieving 
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messages in a standardized format such as email, and accessing a text-to-speech resource. 
The passage says nothing about receiving signals from a recipient of email while the 
email is being rendered which relates to inserting a voice memo at a particular location in 
the email. Claim 1 9 also recites that the voice memo is received and stored and rendered 
as speech to the source of the email. This subject matter is also not described. Wolfe 
clearly does not anticipate claim 19. 

Dependent claims. 

The applicants find it unnecessary to go on and refute the rejection of the 
dependent claims point by point, since the independent claims are clearly not anticipated 
by Wolfe and therefore the dependent claims cannot be anticipated. Suffice it to say that 
the applicants respectfully disagree with the Examiner's reading of Wolfe. 

In view of the above, the prior art rejection of claims 1-33 must be withdrawn. 

Information Disclosure Statement 

Applicants wish to bring to the Examiner's attention a related application to the 
present application, serial no. 10/883,889 filed July 2, 2004. A PTO-1449 form is 
submitted herewith which lists the '889 application, an office action mailed February 19, 
2008 in the '889 application, and the prior art cited in the '889 application. The '889 
application, office action, and non-patent references are also submitted. Consideration of 
the related application, office action and cited art and return of the initialed PTO-1449 
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form is requested. Please charge any required fees for consideration of the Information 
Disclosure Statement to deposit account no. 210765. 

Favorable reconsideration of the application is requested. 



Respectfully submitted. 

McDM^ell Boehnen Hulbert & Berghoff LLP 



By: 



Thomas A. Fair) 
Reg. No. 34591 



